Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

Using the Security Manager

The Security Manager supports the tools under the Security menu in the Administration menu window, and applies security restrictions to an application based on the definitions you create in those tools. See the OpenEdge Development: Progress Dynamics Basic Development chapter on “Using the Toolbar and Menu Designer” for more information on using tools.

This section briefly describes how you can use the manager’s API in your own application code.

The API includes calls to change a user’s password (changePassword), validate a user for a given login ID, password, and company (checkUser), and other useful calls that you can make from your own applications. In addition, there is a set of calls for the various types of security allocations that we described in OpenEdge Development: Progress Dynamics Basic Development : field-level, data-level, access-token, data-range, etc. You can use these calls from any existing application to take advantage of both the login and user validation mechanism in the framework, and also to define security checks in existing application code based on the data structure and supporting tools in Progress Dynamics. You can also use these calls to make security checks in places where the framework does not automatically do it for you.

To see how this is done, you can add a security check to the browser custom super procedure you have been working on. This check allows the system administrator to disable the use and setting of browse profile settings on a per-user basis.

To add a security check:

Define a security token to represent the use of profiles and the browse pop-up menu, and then apply a restriction to a user based on that token.
Select Token Security Control from the Security menu, as shown:



Press the Add button, define a Token Code of BrowsePopup, and give it a Token Description. When you define the Description, keep in mind that this is the field that the Security Allocation tool sorts on to display all the tokens for you, so give it text beginning with Browse Popup, so that you can locate it easily, as shown:



Save this new token. Select the Security Structure tab just to remind yourself that, by default, a security token is defined for all Product Modules, all objects, and for any possible Attribute Code that might be passed in to the object, as shown:



Note: You can create more specific security structures to apply restrictions to in the Structure tab. For example, you can restrict the use of the pop-up menu for only certain windows or certain products.
Define a restriction for a user based on this token.
Open the Security Allocation window from the Security menu, as shown:



Enter a User Name.
Select Access Tokens as the Security Type and select Refresh. All access tokens are displayed. Locate the one for the BrowsePopup token and double-click on the Restricted? field to set it to YES.
Save and exit.
Add code to the browser custom procedure to check for this code. The call you use is tokenSecurityCheck, as shown:

RUN tokenSecurityCheck IN gshSecurityManager (INPUT pcObjectName, INPUT pcAttributeCode, OUTPUT pcSecurityOptions).

It takes these parameters:

INPUT pcObjectName (CHARACTER) — The current container name (with no path, if it’s a physical filename).
INPUT pcAttributeCode (CHARACTER) — The run-time attribute code, if any, passed in to the container.
OUTPUT pcSecurityOptions (CHARACTER) — A comma-separated list of security tokens for which the current user is restricted.

In a case such as this one, where the token is defined for all objects, it would make sense to pass in a blank value for the pcObjectName parameter. However, the procedure will not return anything if you do this, so the application code uses the container name that is already available.

In browsercustom.p, go into the initializeObject procedure and define a variable called cSecurityobjects. The existing code already retrieves the LogicalObjectName of the browser’s container, so we can use that value for our call as well, as shown in the following example:

/* Get the name of the container we're in, which is needed by both the tokenSecurityCheck and the profile data key. */ {get ContainerSource hContainerSource}. IF VALID-HANDLE( hContainerSource ) THEN {get LogicalObjectName cContainerName hContainerSource} NO-ERROR. ELSE cContainerName = "".

Add a call to tokenSecurityCheck, passing in the container name, and getting the token list back. Check for the BrowsePopup token in the list, and if it is there, just RETURN, as shown:

/* Example of using the Security Manager. If the token BrowsePopup comes back for this user, then skip all the profile code. */ RUN tokenSecurityCheck IN gshSecurityManager (INPUT cContainerName, /* pcObjectName */ INPUT "", /* pcAttributeCode */ OUTPUT cSecurityobjects). IF LOOKUP("BrowsePopup", cSecurityobjects) NE 0 THEN RETURN.

Note that the way this is coded, not only does the pop-up menu not get created, but any existing profile settings are not read out of the Repository, either. You could, of course, make this code work any way you want.

Save and compile this change, delete any current running instance of the browsercustom.p procedure, re-logon as the user you defined the restriction for, rerun your test window, and the pop-up menu should not be active. Also, any previously defined profile settings for the browse will not be applied.